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(54) A method for controlling execution of an audio video interactive program 



(57) In an audio video interactive (AVI) receiver 
receiving a packet stream including a directory and an 
AVI program having an associated identifier in the direc- 
tory, a method is disclosed for controlling the execution 
of the AVI program comprises the following steps. First, 
loading the AVI program into a memory in response to 
the presence of the AVI program in the packet stream. 
Then beginning execution of the loaded AVI program. 
And then minimizing the executing AVI program when a 
directory identifying a different AVI program is detected 
in the packet stream. 
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Description 

[0001] The present invention relates to a method for 
controlling the execution of an audio video interactive 
(AVI) executable program component. 5 
[0002] Interactive television systems have been pro- 
posed in which a television receiver includes a proces- 
sor programmable by the broadcaster and capable of 
responding to data entered by the user, generating on- 
screen graphic displays overlaid upon the broadcast w 
video, generating sounds combined with the broadcast 
audio and/or exchanging data with the broadcaster or 
other outside data processing service. In such a sys- 
tem, the broadcast location includes a computer system 
for generating interactive application program informs- is 
tion, including executable code and data, and combin- 
ing the interactive application program information as an 
additional component with the video and audio compo- 
nents of the associated television signal. The processor 
in the television receiver receives the interactive appli- 20 
cation program information from the broadcaster, exe- 
cutes the interactive application program represented 
by that information, generating the graphics and sounds 
to be combined with the television video and audio, and 
processing user inputs received via a remote control 25 
unit. 

[0003] In a proposed AVI system, the composite AVI 
signal from the broadcaster is broadcast in the form of a 
packet data stream, including a plurality of time multi- 
plexed packet services. Each packet service carries a 30 
different component signal of the composite AVI signal. 
For example, one service carries the video component, 
another carries the audio component, and another car- 
ries the interactive application program information 
component. There may be still other services carrying 35 
stereo and SAP audio channels, and/or closed caption- 
ing information, etc. In addition, some packet data 
streams may include packet services carrying compo- 
nent signals for more than one AVI program. Each 
packet service has a unique service component identi- 40 
fier (SCID) associated with it and the packets in that 
packet service each include that service identifier. 
[0004] Further, in the proposed AVI system, one 
packet service carries a program guide and includes a 
predetermined service identifier. The data carried by the 45 
program guide packet service associates the compo- 
nents of an AVI program with the service identifiers of 
the packet services carrying those components. Using 
this data, the packet services carrying the components 
of the desired AVI program may be extracted from the so 
packet stream. 

[0005] The component signals in the AVI signal packet 
data stream are carried by one or more transmission 
units, each consisting of a plurality of packets. A first 
packet in any transmission unit is a header packet, and ss 
the remaining packets in the transmission unit are asso- 
ciated data packets. The header packet contains infor- 
mation about the following data, and the associated 



data packets carry the data making up that portion of 
the component signal. Different transmission units may 
include different numbers of data packets, and the par- 
titioning of the component signals into transmission 
units may be influenced by the timing necessary to 
deliver the different component signals to the viewer 
locations at desired times, or other real time considera- 
tions. 

[0006] The interactive application program information 
component consists of one or more code modules (con- 
taining executable code), possibly one or more data 
modules, and a directory module which includes data 
describing the code and data modules making up the 
interactive application program component. These mod- 
ules are continuously repeated in the application pro- 
gram data component flow. The modules are each 
uniquely identified, and are carried by transmission 
units, as described above, in which the header packet 
contains the identifier of the module and the location 
within that module where the data in the following data 
packets belongs. The interactive application program 
information component also includes special signal for 
controlling the execution of the AVI application program. 
For example, one signal may instruct a currently execut- 
ing AVI application program to suspend execution; 
another may instruct a currently suspended AVI applica- 
tion program to resume execution; and another may 
instruct the currently executing AVI application program 
to cease execution. These signals may be incorporated 
into signal packets within the AVI program component 
packet service. 

[0007] A processor in an AVI receiver, under the con- 
trol of the system loader, first extracts the directory mod- 
ule from the data flow, and utilizes the information 
contained in the directory to determine which code 
module is first to be executed. That code module, called 
the autostart module, is then extracted from the data 
flow and loaded into the memory. When the autostart 
module has been completely loaded into memory, the 
processor begins to execute that code module. During 
the course of its execution, that code module may 
request data from data modules identified in the direc- 
tory module. Those data modules are then extracted 
and loaded into memory. When the module has been 
completely loaded into memory, the requesting code 
module is notified, and execution continues to process 
that data. It is also possfole for one code module to 
chain to a subsequent one. In such a case, the current 
code module issues a request to chain to a new code 
module listed in the directory module, and its memory 
space is freed. The requested code module is then 
extracted from the data flow, and loaded into memory. 
When it has been completely loaded into memory, it is 
executed. Other functions are possible, and will be 
described below. 

[0008] Unlike other distr touted computer systems, the 
AVI program component being received by the AVI 
receiver may change at any time. For example, an AVI 
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program may be interrupted by a non-AVI commercial or 
by an AVI commercial, which, of course, includes a dif- 
ferent AVI program. Or a viewer may change channels 
from one AVI program to another AVI program. It is nec- 
essary to maintain proper synchronization between the 
AVI executable code, and the sound and graphics being 
generated by that code, and the audio and video com- 
ponents being received. 

[0009] In accordance with principles of the present 
invention, in an audio video interactive (AVI) receiver 
receiving a packet stream including a directory and an 
AVI program having an associated identifier in the direc- 
tory, a method for controlling the execution of the AVI 
program comprises the following steps. First, loading 
the AVI program into a memory in response to the pres- 
ence of the AVI program in the packet stream. Then 
beginning execution of the loaded AVI program. And 
then minimizing the executing AVI program when a 
directory identifying a different AVI program is detected 
in the packet stream. 
[001 0] In the drawing: 

FIGURE 1 is a block diagram of a portion of an AVI 
signal decoder, incorporating the present invention; 
FIGURE 2 is a software structure diagram of the 
software executed by the processing unit 40 illus- 
trated in FIGURE 1; 

FIGURE 3 illustrates flow diagrams and memory 
layout diagrams useful in understanding the extrac- 
tion of modules from the data component in an AVI 
program; 

FIGURE 4 is a diagram, partially in block form and 
partially in memory layout form also useful in under- 
standing the extraction of modules from the data 
component of an AVI program; 
FIGURE 5 is a flow diagram illustrating the initializa- 
tion function of the system loader; and 
FIGURE 6 is a state transition diagram illustrating 
the data stream monitoring function of the system 
loader. 

[001 1 ] FIGURE 1 is a block diagram of a portion of an 
AVI signal decoder, incorporating the present invention. 
A decoder as illustrated in FIGURE 1 is installed in each 
viewer location at which it is desired to participate in AVI 
programs. In FIGURE 1, a transport mechanism (not 
shown) is coupled to an input terminal 5 of the decoder. 
Input terminal 5 is coupled to an input terminal of a tuner 
10. An output terminal of tuner 10 is coupled to a data 
input terminal of an AVI program component detector 
30. A data output terminal of program component detec- 
tor 30 is coupled to a system bus 416 of a processing 
unit 40. Processing unit 40 includes a central process- 
ing unit (CPU) 410, a read/write memory (RAM) 412 
and a read-only memory (ROM) 41 4 coupled together in 
a known manner via the system bus 416. A stream I/O 
adapter 408 is bidirectionally coupled between the sys- 
tem bus 416 and a control terminal of the program com- 



ponent detector 30. 

[0012] An audio processor 41 8, coupled to the system 
bus 416, provides an audio signal to AVI audio output 
terminal 25, and a video processor 420, also coupled to 

5 the system bus 41 6, provides a video signal to AVI video 
output terminal 15. Further input and output facilities are 
provided by an I/O port 422, coupled to a collocated 
local processor (not shown) via a bidirectional terminal 
45; user I/O adapter 424, for receiving data from a user 

io via an input terminal 35; and a modem 426, coupled to 
an outside computer (not shown) via a bidirectional ter- 
minal 55; all also coupled to the system bus 416 in a 
known manner. Other equipment, e.g. math processors, 
other I/O adapters, etc., may be coupled to system bus 

is 416 in a known manner. In addition, a bus extender may 
be included for coupling to other equipment in enclo- 
sures external to the decoder enclosure. 
[0013] In operation, the transport mechanism, which, 
for example, may be a direct RF satellite link, a cable 

20 system feed or a fiberoptic link to the decoder, carries a 
plurality of AVI signals, any one of which may be 
selected by the user for viewing. In a direct satellite link, 
for example, a plurality of AVI data streams may be fre- 
quency multiplexed on the transport mechanism by 

25 modulating respective RF carrier signals. Each RF car- 
rier signal is rebroadcast from a respective transponder 
in the satellite to the viewer location. Tuner 10 selects a 
desired RF modulated signal, under the control of proc- 
essor 40, in a known manner. For example, in the direct 

30 satellite system, the RF modulated signal containing the 
packet services carrying the components of the desired 
AVI program signal is tuned by a known RF tuner. The 
output of tuner 10 is a baseband digital packet data 
stream containing those packet services. 

35 [0014] CPU 410 requests desired packet services 
from the program component detector 30 by writing the 
desired service identifiers and RAM 412 buffer locations 
into appropriate service component identifier (SCID) 
and direct memory access (DMA) controller registers in 

40 the program component detector 30 via the stream I/O 
adapter 408. The program component detector 30 then 
monitors the packet data stream for the desired packet 
services. When header packets from any of the desired 
packet services are received, they are stored in a prede- 

45 termined header packet buffer in the RAM 412 using 
known DMA write techniques, and a header packet 
interrupt is generated. When data packets from any of 
the desired packet services are received, they are 
stored in the previously specified buffer locations in the 

so RAM 412 also using known DMA write techniques. 
When all the data packets in a transmission unit have 
been received, a data complete interrupt is generated. 
Reception of header and/or data packets from a packet 
service may be enabled and disabled under control of 

55 the CPU 410. See U.S. Patent Application: Ser. No. 
232,787, PACKET VIDEO SIGNAL INVERSE TRANS- 
PORT PROCESSOR MEMORY ADDRESS CIR- 
CUITRY, by K.E. Bridgewater et al. ffled 4/22/94 for a 
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more detailed description of the program component 
detector 30. 

[001 5] For example, when a new RF modulated signal 
is tuned by the tuner 10, the packet service containing 
the program guide is requested by the CPU 410 by sup- s 
plying the fixed program guide service identifier to a 
service identifier register in the program component 
detector 30. When the data in the program guide pack- 
ets has been received and stored in memory, that data 
allows the CPU to request the packet data services for w 
the desired AVI program. 

[001 6] After packets in the requested packet services 
are received by the program component detector 30, 
and are written via DMA into the previously specified 
buffer locations in RAM 412, the video processor 420 is 
and audio processor 418 read the data from the RAM 
412 buffer locations associated with their respective 
packet services, using known DMA read techniques, 
under control of the program component detector 30. 
Video processor 420 and audio processor 418 then 20 
decode the compressed and encoded data to produce 
the AVI video signal at output terminal 15, and the AVI 
audio signal at output terminal 25, respectively. It is also 
possible for CPU 410 to cooperate with the video proc- 
essor 420 and/or audio processor 418 in the decoding 25 
process. The data component packet service packets 
are processed under the control of the CPU 410 in a 
manner described below. 

[0017] As described above, whenever a header 
packet from a requested packet service is received by 30 
the program component detector 30, it is stored in a pre- 
determined location in RAM 412 for that packet service, 
and a header packet interrupt signal is generated for the 
CPU 410. In response to the header packet interrupt 
signal, an interrupt handler is executed which analyses 35 
the contents of the header packet and either appropri- 
ately updates the RAM 412 buffer locations in the DMA 
registers in the program component detector 30 and 
enables the DMA transfer, or disables the DMA transfer 
if the transmission unit is not desired. Once the DMA 40 
transfer is enabled, the data in the data packets is then 
loaded into RAM 412 under DMA control. When the 
loading of the data packets is completed, the program 
component detector 30 generates a data complete 
interrupt signal. In response to the data complete inter- 45 
rupt signal, an interrupt handler is executed to perform 
"clean-up" functions and prepare for the next header 
packet. 

[0018] FIGURE 2 is a structure diagram of software 
200 executed by the processing unit 40 illustrated in so 
FIGURE 1. FIGURE 2 illustrates the major software 
components making up the AVI processing multitasking 
operating system: In FIGURE 2, all the components are 
stored in the ROM 414, except the application program, 
indicated by the darken area. The application program 55 
is carried by the data component of the AVI signal, is 
received from the broadcast location and is stored in 
RAM 412. The software components illustrated in FIG- 



URE 2 represent executable code and associated con- 
stant data. As the code executes, it may generate and 
access variable data, which is stored in the RAM 412. 
[0019] In the proposed AVI broadcast system, differ- 
ent decoders may use CPUs using different instructions 
sets. e.g. from different manufacturers. In this system, 
the application program is processor independent inter- 
mediate code. The software in each decoder includes a 
component which interprets the intermediate applica- 
tion code (INTERPRETER). This enables the broadcast 
application program to be executed on decoders con- 
taining any type of CPU 410. That interpreter will read 
the AVI data component instructions in intermediate 
code from the RAM 412, manipulate memory, and inter- 
act with the hardware through other software compo- 
nents via an application programming interface (API). 
This API, which is basically a list of subroutines availa- 
ble to an application program and the information nec- 
essary to call them, is published and may be used by 
the application programmer to access the decoder ele- 
ments. 

[0020] A math library performs all the functions 
needed to implement integer and floating point arithme- 
tic. A flow operating system controls all the drivers nec- 
essary to monitor the data component of the AVI signal, 
and process requested modules, as will be described in 
more detail below. A user interface management com- 
ponent handles all the user interaction, and utilizes a 
graphics library, and an event manager to communicate 
with the user. The graphics library performs all the gen- 
eration of graphic images to overlay on the received AVI 
video, and uses the math library for drawing complex 
curves. 

[0021] The different software components of the 
decoder software communicate with other asynchro- 
nously by sending messages to each other. Each pro- 
gram component has a message queue and operates 
by repeatedly reading the next message from the 
queue, processing that message, possibly sending a 
message to another program component, and, if no 
more messages are pending, waiting for the next mes- 
sage. The event manager manages the communication 
of these messages among the other software compo- 
nents by properly routing the messages and maintain- 
ing the message queues. 

[0022] Each hardware adapter also includes an asso- 
ciated software driver. The driver performs the actual 
interaction between the CPU 410 and the registers in 
the associated hardware adapter via the system bus 
416. For example, there are drivers for the modem 426, 
the external I/O port 422, the stream I/O adapter 408 
and the user I/O 424. In addition, separate drivers main- 
tain a software timer and operate the front panel of the 
decoder. These drivers are closely dependent on the 
event manager. All of the above components use com- 
mon functions provided by a multitasking kernel. For 
example, the kernel maintains process priorities, active 
task queues, signals, semaphores, preemptive task 
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switching clock ticks, interrupts (hardware and soft- 
ware), and process stacks. In addition, the kernel pro- 
vides hardware initialization and initiation of the first 
system task, which is a system loader. 
[0023] At initiation, the system loader executes API s 
calls to the flow operating system, which in turn calls the 
stream driver to send the appropriate data to the pro- 
gram component detector 30 via the stream I/O adapter 
408. These API calls from the system loader initiate a 
scan of the data component packet service for the direc- 10 
tory module in a manner described in more detail below. 
When the directory module is found, it is loaded into 
RAM 412, and checked to see if all of the required 
resources to execute that program are available. H so, 
then the system loader initiates a scan of the AVI data 75 
component for the first module, termed an autostart 
module, which will initiate the AVI program. When the 
autostart module is located, it is extracted from the data 
component packet service and loaded into RAM 412. 
This autostart module is in the form of intermediate 20 
code, and is executed by being interpreted by the inter- 
preter. The autostart module performs the remainder of 
the initialization and begins execution of the AVI pro- 
gram. This program may possibly load other code and 
data modules, and chain to another code module, all via 25 
API calls. In this manner, the system loader operates in 
the same manner as a classic UNIX® shell. 
[0024] In addition, the system loader continues to 
scan the data component packet service comparing 
transmitted directory modules to the current directory 30 
module in RAM 412. If the transmitted directory module 
is different than that stored in RAM 412, it indicates that 
the data component packet service has changed, for 
example, such as when a viewer changes channels, or 
an interactive commercial is being broadcast In this 35 
case, a message is sent to the application program via 
the event manager using the API. In response to this 
message, the application program deallocates all its 
resources, and maintains only a minimal presence in 
the processing element 40. For example, the memory 40 
used to store all code and data modules may be freed, 
and only the execution state of the application kept in 
RAM 412. When the minimization of the application pro- 
gram has completed, a message is sent to the system 
loader. 45 
[0025] The system loader then allocates the 
resources necessary to execute the AVI program repre- 
sented by the new directory module. When a new direc- 
tory module is detected in the AVI data component 
packet service, a list of previously minimized appiica- so 
tions is searched, and if the application represented by 
the new directory is present, that application is resumed 
by reloading the necessary" code and data modules 
from the data component flow, and resuming execution 
from where it had previously been halted. This may hap- ss 
pen at the end of an intervening interactive commercial. 
This process may be recursive, where a second AVI 
program may, itself, be interrupted by a third AVI pro- 
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gram, and later reactivated. 

[0026] FIGURE 3 illustrates flow diagrams and mem- 
ory layout diagrams and FIGURE 4 is a more detailed 
block diagram of the program component detector 30 
(of FIGURE 1) and a more detailed memory layout dia- 
gram useful in understanding the extraction of modules 
from the data component in an AVI program. In FIGURE 
4, the baseband digital packet stream from tuner 10 (of 
FIGURE 1) is coupled to respective data input terminals 
of a data DMA controller 32 and a header packet DMA 
controller 34 within the program component detector 30. 
Respective data output terminals of data DMA controller 
32 and header packet DMA controller 34 are coupled to 
the system bus 416 of the processing unit 40. The 
stream I/O adapter 408 is coupled between the system 
bus 416 and respective control input terminals of the 
data DMA controller 32 and the header packet DMA 
controller 34. In operation, stream I/O adapter 408 sup- 
plies control information, e.g. buffer location start and 
end addresses, read and write addresses, and transfer 
counts, in known manner from CPU 410 (of FIGURE 1 
to the data DMA controller 32 and the header packet 
DMA controller 34. Stream I/O adapter 408 may then 
enable the data DMA controller 32 and/or the header 
packet DMA controller 34 to transfer data or header 
packets, respectively, from the packet stream to the 
buffer in a known manner, or disable such transfers, 
under control of the CPU 410. When the data DMA con- 
troller 32 completes a data transfer, it generates a data 
complete interrupt for CPU 410. When the header 
packet DMA controller 34 completes loading a header 
packet, it generates a header packet interrupt for CPU 
410. 

[0027] Also in FIGURE 4, the RAM 41 2 is represented 
by a large block, and data structures are represented by 
smaller blocks within the large block. The blocks in FIG- 
URE 4 are schematic only, and are not meant to illus- 
trate either absolute or relative locations or sizes 
allocated in the RAM 41 2 for the data structures. In 41 2, 
a module request queue 322, a header packet buffer 
324, a directory module buffer 326 and a module buffer 
328 data structures are illustrated. Fields of information 
within the data structures are illustrated as horizontal 
slices containing the name of the type of information 
contained in that field. These will be discussed in detail 
below. 

[0028] FIGURE 3 illustrates the procedure followed in 
extracting a module from the data component packet 
service and storing it in a buffer in RAM 412. Similar 
procedures are followed for other module processing, 
as will be described below. In FIGURE 3, actions taken 
in an application program (or the system loader) are 
illustrated in the left hand column under the heading- 1 
"APPLN PROG.". In block 302, the application program, 
using the API, makes a request to the flow operating 
system to load a module having the identifier ID from 
the AVI program component packet service. As 
described above, API calls are basically subroutine 
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calls to operating system functions. The program execu- 
tion is, thus, transferred to the flow operating system 
(FOS). Actions taken by the FOS are illustrated in the 
next column to the right, under the heading "FOS." 
• Because the request involves the loading of a module, 
in block 312 the FOS requests a memory allocation 
from the memory manager of sufficient size to contain 
the module. For example, if the requested module is a 
code or data module, the previously stored directory 
module 326 (of FIGURE 4) includes a field containing 
the length (LENGTH) of the module ID. In this case a 
memory manager allocates a module memory buffer 
(328 of FIGURE 4) having a starting address START 
and an ending address END. Then, in block 314, infor- 
mation describing the request, e.g. the identifier ID of 
the module, the type of request REQUEST (in this case 
a request to extract and load a module) and the allo- 
cated buffer starting address START, and ending 
address END, are all stored in the entry in the request 
queue (QUEUE) 322. The header packet DMA control- 
ler 34 is then enabled to load header packets into the 
RAM 412, when they occur in the packet stream. 
[0029] If the request is for the directory module, its 
length is not known a priori In this case a relatively 
large memory allocation is requested. If this allocation 
turns out to be too small, the request is repeated, after 
requesting a larger memory allocation, until either the 
directory module is loaded, or it is determined that there 
is insufficient memory to load it, in which case the 
attempt to run the AVI program is abandoned. 
[0030] The FOS then immediately returns to the call- 
ing application program. The application program is 
then able to perform other processing, for example issu- 
ing requests for other modules, other intializations. etc. 
When access to the requested module is required, the 
application program, in block 304, may issue an API call 
to a wait function in the kernel. This function suspends 
the execution of the application program until a mes- 
sage indicating the successful loading of the requested 
module is received by that application program. When 
such a message is received, the application program is 
reactivated to process that message. Alternatively, the 
application program may remain active, e.g. in order to 
respond more quickly to user inputs, and periodically 
poll its message queue for the message indicating suc- 
cessful loading of the requested module, and process 
the message when it is received. 
[0031] As described above, the header packet DMA 
controller 34 loads header packets into a header packet 
(HDR PKT) buffer 324 (of FIGURE 4) in the RAM 412 
previously allocated by the memory manager, and 
issues a header packet interrupt to the CPU 410. A por- 
tion of the processing performed by the header interrupt 
handler in the kernel is illustrated in the column headed 
"HEADER INTR" in FIGURE 3. In block 332. the identi- 
fier of the module which is being carried in the transmis- 
sion unit for which this is the header packet, is retrieved 
from a known location, ID, in the header packet buffer 



324. In block 334, request queue 322 is examined to 
determine if there is a pending request for ttris module. 
[0032] If there is a pending request for that module, 
then, in block 336, the data packet DMA controller 32 in 
s the program component detector 30 is initialized with: 
the module buffer 328 starting address START and end- 
ing address END from the request queue 322; a write 
address which is the sum of the module buffer 328 start- 
ing address START and the transmission unit data off- 
io set OFFSET (i.e. START + OFFSET); and a last write 
address which is START + OFFSET + SIZE (or alterna- 
tively, a load count which is the size SIZE from the 
header packet buffer 324 in place of the last write 
address). The data packet DMA controller 32 is then 
is enabled. 

[0033] In block 338. rf this is the first header packet 
received after the load request was made, a pointer to 
the first write address, FIRST, stored in the request 
queue 322, is initialized to the write address of this first 
20 transmission unit (i.e. FIRST = START + OFFSET). In 
addition, a pointer to the expected next write address, 
NEXT, also stored in the request queue 322, is also ini- 
tialized to the write address of the first transmission unit 
(i.e. NEXT = START + OFFSET). Other processing is 
25 then performed in block 338, which wiD be described in 
more detail below. For example, a special pointer to the 
location in the request queue 322 of the request cur- 
rently being processed, CURR REQ, is stored in a pre- 
determined location (not shown) in RAM 412. Then, in 
30 block 339. the interrupt handler returns (339) 

[0034] The data packet DMA controller 32 initializes a 
write pointer (WP) to the previously received write 
address (START + OFFSET) and loads data from the 
following data packets in the AVI program component 
35 packet service into sequential locations in the module 
buffer 328 in RAM 412. When all the data in the trans- 
mission unit has been loaded into RAM 412. the data 
complete interrupt is generated. A portion of the 
processing performed by the data complete interrupt 
40 handler in the kernel is illustrated in the right hand col- 
umn headed "DATA COMPL INTR" of FIGURE 3. 
[0035] In block 342 clean-up functions related to the 
current status of the DMA transfer are executed. The 
current request pointer (CURR REQ), previously set in 
45 the header packet interrupt handler, points to the entry 
in the request queue 322 for which a transmission unit 
has just finished loading. The expected next write 
address pointer, NEXT, in the current request is incre- 
mented by the value SIZE from the header packet buffer 
so 324, and now points to the write address expected for 
the next transmission unit. If the new value of the 
expected next write address pointer, NEXT, is equal to 
the ending address, END, of the module buffer 328. it is 
reset to the starting address, START, of the module 
55 buffer 328. in wrap-around fashion. 

[0036] In block 344 it is determined whether the entire 
requested module has been loaded into memory. The 
value of the expected next write address pointer, NEXT, 
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is compared to the value of the first loaded address, 
START, if they are the same, then the entire module has 
been loaded. In block 346. a message is sent, via the 
event manager, to the requesting application program to 
indicate that the requesting module has been com- 
pletely retrieved, illustrated as a dashed line in FIGURE 
3. In addition, the request is removed from the request 
queue 322. II the value of the expected next write 
address NEXT is not the same as the first loaded 
address, START, the data complete interrupt handler 
returns (349), and the next transmission unit containing 
data for the requested module will be processed by the 
header packet interrupt handler, as described above. In 
either event, the current request pointer (CURR REQ) is 
cleared. 

[0037] If some portion of a transmission unit is not 
properly received by the program component detector 
30, then a subsequent header packet will be received 
before the data complete interrupt signal from the pre- 
ceding header packet has been generated by the DMA 
circuitry in the program component detector 30. This, in 
turn, generates a subsequent header packet interrupt 
signal before the preceding data complete interrupt sig- 
nal can be generated. Processing in the header packet 
interrupt handler and the data complete interrupt han- 
dler can cooperate to identify this situation and provide 
for handling such an error. 

[0038] In the header packet interrupt handler, such 
processing is performed in block 338 (of FIGURE 3), 
after the data packet DMA controller is enabled to 
receive the next transmission unit. For each header 
packet received, the expected next write address, 
NEXT, in the current request queue entry, previously 
updated by the data complete interrupt handler, is com- 
pared to the write address (START + OFFSET) for the 
newly received header packet. If they are the same, the 
previous transmission unit was successfully received. If, 
however, the last ending address is not the same as the 
new offset, that means that the DMA transfer of the pre- 
vious transmission unit did not complete successfully. In 
this case, both the first write address. FIRST, and the 
expected next write address, NEXT, are updated to the 
current write address (START + OFFSET). That is, pre- 
viously loaded transmission units are essentially dis- 
carded, and loading of the module is restarted with the 
current transmission unit. This form of recovering from a 
data missing type of error may take more time, because 
a transmission unit which was previously loaded suc- 
cessfully may result in an error when reloaded. How- 
ever, by using this form of recovery, the tasks performed 
by the header packet interrupt handler and data com- 
plete interrupt handler are minimized, and only two 
pointers are needed in memory. * * * 
[0039] As a part of the module complete message 
handling, the event handler performs an error checking 
on the received module. For example, a cyclic redun- 
dancy check (CRC) code is transmitted as an embed- 
ded part of the module. The event handler calculates a 



CRC over the received module in the module buffer 328 
in the RAM 412, and compares it to the embedded 
CRC. If the newly calculated CRC equals the embedded 
CRC, then the module was correctly received, other- 
5 wise an error occurred, and the module is reloaded, as 
described above. 

[0040] When the requested module has been com- 
pletely loaded into memory further processing by the 
application module may continue, illustrated in FIGURE 

10 3 by inference as a line from the bottom of the API call 
to the watt function 304. However, a separate task in the 
application program may be activated in response to the 
receipt of the message from that application program's 
message queue. 

is [0041] The above mentioned API includes functions 
for accessing the data stream by the application pro- 
gram, via the interpreter, or by the system loader. An 
application programmer will use the published API 
description to formulate an API call to access the 

20 desired data stream function. A first group of functions 
relates to the directory of modules. A first function, 
DIRJMEW, is a request for a new directory. As 
described above, in response to this API function, an 
allocation of memory is made, then a request is 

25 enqueued for the loading of the next directory module in 
the data stream, then the API function returns. When 
the directory has been loaded, a message is sent to the 
requesting program. Another function, DIR_FREE, 
frees the memory space taken by the current directory. 

30 The function DIR_SELECT indicated which directory 
module will be used in subsequent API calls. The func- 
tion DIR_CURRENT returns a handle to the currently 
selected directory. 

[0042] The functions DIR_SPY and DIR_STOP_SPY 

35 are similar to the DIR_NEW function. In response to a 
DIR_SPY API call, a request is enqueued in the request 
queue for a directory module, but instead of loading a 
directory module and sending a message when it is 
loaded, this function sends a message whenever a 

40 directory module is detected in the data flow (the direc- 
tory module is not loaded). In addition, the request 
remains in the request queue until a DIR_STOP_SPY 
API call is made. When a DIR_STOP_SPY API call is 
made, the request queue is searched for the directory 

45 spy request, and that entry is removed. These functions 
are useful in spying any change from the current direc- 
tory in the data stream. Finally there are API calls to 
extract information about the current directory: 
DIRJDENTIFIER, DIR_REQUIREMENT and 

so DIR_NB_MODULES. 

[0043] Because of the embedded CRC code in the 
module, any memory allocation request for loading a 
module must take this code irtttf account Three API 
calls are provided to handle this. The function 

55 MODULE_ALLOC takes a module identifier as an argu- 
ment and requests an allocation of the proper amount of 
memory to load that module, taking into account any 
CRC or other memory requirements. The function 
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MODULE_FREE frees the memory taken by a module. 
MODULE_CHECK performs a CRC check of a loaded 
module and returns the result This may be performed 
at any time because the CRC is embedded in the mod- 
ule as loaded in memory. 5 
[0044] Another set of API calls deals with the mod- 
ules, using the currently selected directory to identify 
them. There are API calls to extract information about a 
module: MODULE_REQUIREMENT, MODULE_SIZE 
and MODULE_FLAGS. These enable the system to w 
determine whether a module may be loaded and/or exe- 
cuted. The function MODULE_RUN is used to load an 
executable module, as described above, create a new 
process, and begin execution at the entry point of the 
module. This function is used by the system loader to is 
initiate AVI program execution. The function 
MODULE_CHAIN is used to load a subsequent execut- 
able module, end execution of the current module, and 
begin execution of the newly loaded module at its entry 
point. No new process is created in this case. The func- 20 
tion MODULEJJ3AD is used to load a module, but not 
start execution. As described above, a message is sent 
to the requesting program when the module loading has 
completed. The function MOD ULE_EXEC is used to 
create a new process and begin execution of a module, 25 
which was previously loaded by the MODULE_LOAD 
API call, at its entry point. 

[0045] The function MODULE JJNK executes a new 
module using the current process, resources and varia- 
bles. It allows for subroutine-like calls from within a mod- 30 
ule by providing a dynamic link to the new module. This 
permits AVI programs to be divided into smaller mod- 
ules which may be dynamically linked only when neces- 
sary. The MODULEJJNK function maintains relocation 
and jump tables. The functions MODULE_SPY and 35 
MODULE_STOP_SPY operate similarly to the 
DIRECTORY_SPY and DIRECTORY_STOP_SPY but 
with respect to identified modules. The MODULE_SPY 
API call inserts an entry in the request queue including 
the identifier of the module. Whenever a header module 40 
with the same identifier is detected in the data stream, a 
message is sent to the requesting program. This contin- 
ues until a MODULE_STOP_SPY API call is made. In 
response to the MODULE_STOP_SPY API call, the 
entry containing the spying request for the identified 45 
module is removed from the request queue. The 
MODULE_STOP_LOAD function stops any module 
loading request currently in process and removes the 
loading request entry from the request queue. The func- 
tions FLOW_MESSAGE and FLOW_STOPJv1ESSAGE so 
respectively generate and remove a request for a mes- 
sage when a special signalling packet relating to the 
data stream occurs," such as a suspended data flow or 
the end of the data flow. When such an event occurs, a 
message is sent to the requesting program. 55 
[0046] As described above, the system loader, per- 
forms system initialization and monitors the data stream 
to ensure that the execution of the application program 



is in synchronism with the received audio and video 
components. FIGURE 5 is a fbw diagram illustrating the 
initialization function of the system loader. In block 52 of 
FIGURE 5, various hardware and software components 
of the decoder (of 17) are initialized. In addition, loca- 
tions in the RAM 412 are allocated and initialized for 
various data structures. These initialization functions 
are well known, and depend upon other software com- 
ponents in the decoder. A system programmer will 
understand what hardware and software initializations 
are required, what data structures are required, and 
how to perform the initializations. Thus, this block will 
not be described in detail below. 
[0047] In block 54 a DIR_NEW API call, described 
above, is made. This API call loads the next directory 
module appearing in the AVI program component 
packet service into an allocated buffer in the RAM 412. 
This API call returns to the system loader immediately 
even though the directory may not be loaded into the 
RAM 412 until a later time. The system loader performs 
other functions and then, if necessary, a wait API call 
(not shown) until a message is received, via the event 
manager, indicating that the directory module has been 
loaded. In block 56, the resources available in the 
decoder (of FIGURE 1) are compared to the data indi- 
cating the required resources, in the directory module. If 
the decoder has sufficient resources to execute the AVI 
program, a MODULE_RUN API call is made to load the 
autostart code module, identified in the previously 
loaded directory module, as described above. Again, 
the API call returns immediately, but the code module 
may not be completely loaded from the data stream until 
some later time. After the autostart code module is com- 
pletely loaded, another task is created in a known man- 
ner using the multitasking kernel for executing the AVI 
program, via the interpreter. 

[0048] In block 58, the system loader begins to moni- 
tor the AVI program component for execution signals, 
and directory changes, and controls the execution of the 
AVI program by sending messages to the AVI program 
as described below. FIGURE 6 is a state transition dia- 
gram illustrating the monitoring function of the system 
loader, and is useful in understanding the operation of 
the system loader. If a directory is detected in an AVI 
program component packet service, then the program 
that the viewer has selected is an interactive program. 
Once the directory has been loaded into the RAM 412, 
and the autostart code module requested from the AVI 
component packet service, the AVI program, under the 
control of the system loader, enters the INACTIVE state 
61. In the INACTIVE state 61, all the resources to start 
the application have been allocated and the application 
may be partially or completely loaded, but there is no" * 
interaction with the viewer. For example, while the auto- 
start module is being loaded, the AVI program remains 
in the INACTIVE state 61. In addition, even after the 
autostart module has been loaded, the viewer may 
merely be changing channels through the channel car- 
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rying the AVI program and have no intention of interact- 
ing with the AVI program. Or the viewer may just wish to 
observe the AVI program before making a decision to 
join the interaction. In all these cases it is important that 
the remote control acts in a normal channel changing 
mode and not in an interactive mode. This is the pur- 
pose of the INACTIVE state 61. In order to notify the 
viewer that the channel being watched is broadcasting 
an interactive program, a special interactive program 
logo or icon is overlaid upon the AVI video. 
[0049] In order for a viewer to actually begin to interact 
with the AVI program, a special key, called "ACTIVATE 
KEY" below, is provided on the remote control. When 
the interactive program logo or icon is displayed, the 
viewer may press the ACTIVATE KEY The system 
loader, in response to the ACTIVATE KEY press, sends 
an ACTIVATE message to the AVI program which, then, 
enters the ACTIVE state 63. In the ACTIVE state 63, the 
interpreter actually begins to execute the previously 
loaded AVI program at its entry point. When the auto- 
start module of the AVI program begins execution, it 
allocates and initializes its own data structures in the 
RAM 412, loads other code and/or data modules and 
controls all user actions from the remote control and 
front control panel. 

[0050] Because the AVt program controls all user 
interaction, it can prevent the user from changing chan- 
nels or performing other normal remote control func- 
tions. In order to revert to normal remote control 
functions, the viewer must first stop the current AVI pro- 
gram. The viewer presses the ACTIVATE KEY, again, to 
deactivate the program. In response to this key press, 
the system loader sends a DEACTIVATE message to 
the executing AVI program, which, then, leaves the 
ACTIVE state 63, and returns to the INACTIVE state 61 . 
Again, the special interactive program logo or icon is 
displayed, indicating that the AVI program is loaded but 
not executing. The viewer may, then, change channels 
or perform other normal remote control functions, or 
may reactivate the AVI program by pressing the ACTI- 
VATE KEY again. The ACTIVATE KEY, thus, acts as a 
toggle to switch between the ACTIVE state 63 and the 
INACTIVE state 61 when it is pressed. The ACTIVATE 
and DEACTIVATE messages may also be thought of as 
ACTIVATE TOGGLE messages, whose meaning (ACTI- 
VATE or DEACTIVATE) depends upon the state of the 
AVI program (INACTIVE or ACTIVE, respectively) when 
the ACTIVATE KEY is pressed. 

[0051] While the AVI program is executing in the 
ACTIVE state 63, there are times when it is desired to 
suspend its execution. For example, when a non-inter- 
active commercial is to be transmitted, the transmitted 
audio and video will no longer match the sound and 
graphics being generated by the decoder 10 (of FIG- 
URE 1). and it is desired to allow the viewer to use the 
remote control in its normal manner. The application 
programmer, however, cannot know in advance when 
such suspensions will be required. Thus, in this case, 



the broadcaster, independent of the AVI program, may 
repetitively include special signal packets (as described 
above), called suspend signal packets, in the AVI pro- 
gram component packet service. Each such packet con- 
5 tains data directing that the currently executing AVI 
program is to suspend execution. 
[0052] The system loader, via a FLOW_MESSAGE 
API call, receives a message whenever such packets 
are recognized in the AVI program component packet 
w service. For example, when a suspend signal packet is 
received, the system loader receives a suspend signal 
message, and, in response to the first suspend signal 
message, sends a SUSPEND message to the AVI pro- 
gram, which, in turn, suspends execution, entering the 
is SUSPENDED state 65. In the SUSPENDED state 65, 
execution of the AVI program halts in such a manner 
that it may be started again from the point where it was 
suspended. That is, all the resources necessary to exe- 
cute the AVI program remain allocated, and the execu- 
te tion state of the AVI program is stored in a location in the 
RAM 412. In addition, a second logo or icon, indicating 
that a previously executing interactive program is sus- 
pended, but ready to resume when allowed, is overlaid 
over the current video image. 
25 [0053] When the interruption (e.g. non-interactive 
commercial) is over, the broadcaster stops including the 
suspend signal packets in the AVI program component 
packet service. The system loader, after a predeter- 
mined period of time without receiving a suspend signal 
30 message, sends a CONTINUE message to the AVI pro- 
gram, which, in turn, resumes execution from where it 
was previously suspended, entering the ACTIVE state 
63, described above. 

[0054] An alternative embodiment of the SUS- 
35 PEND/CONTINUE signalling arrangement, described 
above, is for the broadcaster to include a single sus- 
pend signal packet in the AVI program component 
packet service when it is desired to suspend execution 
of the AVI program. The broadcaster, then, includes 
40 another special signal packet, called a continue signal 
packet, in the AVI program component packet service 
when it is desired to resume execution of the AVI pro- 
gram. This packet contains data directing the currently 
suspended AVI program to resume execution. The sys- 
45 tern loader recognizes the continue signal packet, and 
sends a CONTINUE message to the AVI program, 
which resumes execution and enters the ACTIVE state 
63, as described above. 

[0055] It is also possible for a viewer to stop the exe- 
so cution of a suspended AVI program. When the program 
suspended logo or icon is displayed, the viewer may 
press the ACTIVATE KEY. The system loader, respon- 
sive to this key press: Sends* a DEACTIVATE message 
to the suspended AVI program, which in turn, enters the 
55 INACTIVE state 61. described above. From the INAC- 
TIVE state 61, the program may only resume execution 
when the viewer presses the ACTIVATE KEY, causing 
the system loader to send an ACTIVATE message to the 
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AVI program, which will, then, enter the ACTIVE state 
63. If the system loader is still receiving suspend signal 
packets, another SUSPEND message is immediately 
sent to the AVI program which, again, enters the SUS- 
PENDED state 65. The INACTIVE state 61. ACTIVE 
state 63 and SUSPENDED state 65 are the states 
among which the AVI program may switch in response 
to messages sent to it from the system loader. However, 
there are two other states which are entered under the 
direct control of the system loader. 
[0056] An AVI program can reach an end of its execu- 
tion. For example, the broadcaster may include another 
special signal packet, called an end execution signal 
packet, in the AVI program component packet service. 
The system loader receives an end execution message 
when an end execution signal packet is recognized in 
the AVI program component packet service, via the 
FLOWJvlESSAGE API call. In response to the end exe- 
cution message, the system loader sends an EXIT mes- 
sage to the AVI program. Regardless of what state the 
AVI program is in, INACTIVE 61. ACTIVE 63 or SUS- 
PENDED 65, the AVI program responds to the EXIT 
message by deallocating all its resources, and removing 
all record of itself from the decoder 10 (of FIGURE 1). 
The program is deemed to have entered the HALTED 
state 69, and disappears from the decoder 10. In some 
cases, the program itself can recognize that its execu- 
tion has reached an end, either via a user command, or 
by its own execution. When the AVI program recognizes 
that its execution has ended, it performs the same 
processing that it would have performed had an EXIT 
message been received, and it enters the HALTED 
state 69 on its own accord. 

[0057] When an AVI program is in the SUSPENDED 
state, it is possible that a different interactive AVI pro- 
gram will be received on the AVI program component 
data flow. For example, if the AVI program was sus- 
pended for a commercial, that commercial may itself be 
an interactive program, or the user may have changed 
channels to a channel broadcasting a different AVI pro- 
gram. In both these cases, the new AVI program will 
include a directory module, which is different from that 
for the suspended AVI program. 
[0058] The system loader, via the DIR_SPY API call, 
receives a message whenever a directory is detected in 
the AVI program component packet service. The system 
loader compares the currently active directory to the just 
detected directory. When the system loader recognizes 
that a different directory is present in the AVI program 
component packet service, it begins to load the AVI pro- 
gram represented by that directory. 
[0059] First, a message is sent to the currently sus- 
pended AV1 prograrfVto intficate" that the program com- 
ponent packet service no longer is broadcasting its 
program, or that the program has lost the flow.' This ; 
message is a request for the currently executing pro- 
gram to minimize itself, i.e. is a MINIMIZE message. In 
response to the MINIMIZE message, the currently sus- 



pended AVI program first stores its current execution 
state and environment in a small block of the RAM 412 
containing the identification of the AVI application, and a 
time duration, which will be described below. Then the 
5 suspended AVI program begins to deallocate is 
resources. A minimized AVI program does not include 
any code, and, thus, cannot change states in response 
to messages, or restart itself. 

[0060] The system loader then loads the newly 
10 detected directory and autostart module and places the 
new AVI program in the INACTIVE state 61 displaying 
the interactive program logo or icon, as described 
above. The viewer can then start and stop interaction 
with this new AVI program by pressing the ACTIVATE 
is KEY, and the program may, itself be suspended and 
continued. 

[0061] The minimizing process is a recursive process. 
For example, this new AVI program, if suspended, may 
also be minimized if yet another AVI program is 
20 detected in the AVI program component packet service. 
In this case, another block of memory is allocated, and 
the execution state and environment of this AVI pro- 
gram, along with its identifier and a time duration, is 
stored in this memory block. Then the newly detected 
2$ AVI program is loaded, as described above. The 
number of programs which may simultaneously be min- 
imized is limited only by the amount of memory required 
to store all the memory blocks containing the executions 
states and environments of the minimized programs. 
30 [0062] If there is not enough available memory space 
to load the new directory module, or execute the pro- 
gram represented by a previously loaded directory mod- 
ule, and if there are memory blocks allocated 
representing minimized programs, the system loader 
35 may automatically deallocate some or all of the memory 
blocks according to an algorithm (such as deallocating 
the oldest memory block first, or first deallocating mem- 
ory blocks marked as expendable by the originating 
application) in an attempt to derive sufficient memory 
40 space. Alternatively, the system loader may present a 
list of minimized applications to the viewer, and allow 
the viewer to select some or all for deletion. Blocks rep- 
resenting selected minimized applications are then 
deallocated to derive sufficient memory space. 
46 [0063] In the meantime, the memory blocks containing 
the execution states and environments of previously 
minimized AVI programs remain allocated in memory. 
As described above, there is a time duration in each 
such memory block. If the time duration in any block is 
so exceeded, then that previously minimized AVI program 
times out. In this case, that program is considered to 
have entered the HALTED state 69, and its block of 
memory containing the execution state' arid environ- 
ment is deallocated, and all record of that previously 
»5 minimized AVI program is lost. 

[0064] However, it is possible for the decoder 10 to 
again receive an AVI program component containing 
the directory, code and data modules of a previously 
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minimized AVI program, or for that AVI program to 
Yegain the flow.' For example, the interactive commer- 
cial may have terminated, entering the HALTED state 
69, or the viewer may have changed the channel back to 
this channel. The system loader begins to load the 'new' 5 
directory in the AVI program component packet service. 
Whenever a new directory is loaded, the application 
identifier is compared to the identifiers in all blocks con- 
taining execution state and environments currently 
stored in the RAM 412. If a matching block is found, io 
then the code and data modules are loaded, and the 
AVI program placed in the INACTIVE state 61, but its 
execution state is updated to that just before it was min- 
imized. When the viewer presses the ACTIVATE KEY, 
the AVI program enters the ACTIVE state 63, and 15 
begins execution where it previously left off. In this man- 
ner, an AVI program may be temporarily stopped to run 
another AVI program, and then resumed, without requir- 
ing sufficient resources for both programs to remain in 
memory simultaneously. 20 

Claims 

1. In an audio video interactive (AVI) receiver receiv- 
ing a packet stream including an AVI program and 25 
execution signals, and including an execution con- 
troller for controlling the execution of the AVI pro- 
gram, a method for controlling the execution of the 
AVI program characterized by the steps of: 

30 

in the execution controller: 

loading the AVI program into a memory in 
response to the presence of the AVI pro- 
gram in the packet stream; 35 
sending an activate toggle message to the 
AVI program in response to a user input; 
sending an exit message to the AVI pro- 
gram in response to an end execution sig- 
nal in the packet stream; 40 
sending a suspend message to the AVI 
program in response to a suspend execu- 
tion signal in the packet stream; and 
sending a continue message to the AVI 
program in response to a continue execu- 45 
tion signal in the packet stream; and 

in the AVI program: 

executing in one of: so 

an inactive state, in which the AVI pro- 
gram is irtstetiver 

an active state, in which the AVI pro- 
gram is executing; and ss 
a suspended state, in which execution 
of the AVI program is suspended; 



entering the inactive state, in response to 
the loading of the AVI program into the 
memory; 

halting execution, and unloading the AVI 
program from the memory in response to 
the exit message; 

when in the inactive state, entering the 
active state in response to an activate tog- 
gle message; 
when in the active state: 

entering the inactive state in response 
to the activate toggle message; and 
entering the suspended state in 
response to a suspend message; and 
when in the suspended state: 
entering the active state in response to 
a continue message; and 
entering the inactive state in response 
to an activate toggle message. 

2. The method of claim 1, characterized in that: the 
suspend execution signal in the packet stream is 
represented by repetitive suspend execution signal 
packets during a suspend time interval, and the 
continue execution signal is represented by no 
repetitive suspend execution signal packets; and 

the step of sending a suspend message in the 
execution controller comprises the step of 
sending the suspend message in response to a 
first suspend execution signal packet; and 
the step of sending a continue message in the 
execution controller comprises the step of 
sending a continue message after a predeter- 
mined time period in which no suspend execu- 
tion signal packets are received. 

3. The method of claim 1 , characterized in that: 

the suspend execution signal in the packet 
stream is represented by a suspend execution 
signal packet and the continue execution signal 
is represented by a continue execution signal 
packet; and 

the step of sending a suspend message in the 
execution controller comprises the step of 
sending the suspend message in response to a 
suspend execution signal packet; and 
the step of sending a continue message in the 
execution controller comprises the step of 
sending a continue message in response to a 
continue execution signal packet. 

4. In an audio video interactive (AVI) receiver selec- 
tively receiving one of a plurality of packet streams 
under control of a user, each packet stream includ- 
ing an AVI program having an identifier, and execu- 
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tion signals, the receiver including an execution 
controller for controlling the execution of the AVI 
program, a method for controlling the execution of 
the AVI program characterized by the steps of: 

in the execution controller: 

loading the AVI program into a memory in 
response to the presence of the AVI pro- 
gram in the selected one of the plurality of 
packet streams, storing the identifier of the 
loaded application program into a respec- 
tive location in the memory, and searching 
blocks previously stored in the memory 
containing identifiers of minimized AVI pro- 
grams and if an identifier contained in a 
block matches the identifier of the AVI pro- 
gram loaded into the memory, setting the 
execution state and environment of the 
newly loaded AVI program to an execution 
state and environment contained in the 
matching block; 

sending an activate toggle message to the 
AVI program in response to a user input; 
sending an exit message to the AVI pro- 
gram in response to an end execution sig- 
nal in the selected one of the plurality of 
packet streams; 

sending a suspend message to the AVI 
program in response to a suspend execu- 
tion signal in the selected one of the plural- 
ity of packet streams; and sending a 
continue message to the AVI program in 
response to a continue execution signal in 
the selected one of the plurality of packet 
streams; 

sending a minimize message to the AVI 
program in response to the presence of an 
AVI program in the data stream having a 
different identifier than the identifier in the 
respective location in the memory; and 

in the AVI program: 

executing in one of: 

an inactive state, in which the AVI-pro- 
gram is inactive; 

an active state, in which the AVI pro- 
gram is executing; 

a suspended state, in which execution 
of the AVI program is suspended; and 
a minimized state, including the steps~ 
of: 
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halting execution of the AVI pro- 
gram; then 

storing the identifier of the AVI 



55 



program and the execution state 
and environment of the AVI pro- 
gram in a block of the memory; 
then 

unloading the AVI program from 
the memory; 

entering the inactive state, in response to 
the loading of the AVI program into the 
memory; 

halting execution, and unloading the AVI 
program from the memory in response to 
the exit message; 

when in the inactive state, entering the 
active state in response to an activate tog- 
gle message; 
when in the active state: 

entering the inactive state in response 
to the activate toggle message; and 
entering the suspended state in 
response to a suspend message; and 
when in the suspended state: 
entering the active state in response to 
a continue message; 
entering the inactive state in response 
to an activate toggle message; and 
entering the minimized state in 
response to the minimize message. 

5. The method of claim 4, characterized in that the 
storing step in the step of executing in a minimized 
state in the application program further comprises 
the step of: 

storing a time duration in the block of memory, 
indicating a period of time during which the 
data stored in the block of the memory will 
remain in the memory and, after the time dura- 
tion has expired, removing the data stored in 
the block of memory. 

6. The method of claim 4, characterized in that: 

the suspend execution signal in the selected 
one of the plurality of packet streams is repre- 
sented by repetitive suspend execution signal 
packets during a suspend time interval, and the 
continue execution signal is represented by no 
repetitive suspend execution signal packets; 
and 

the step of sending a suspend message in the 
execution controller comprises the" step" of 
sending the suspend message in response to a 
first suspend execution signal packet; and 
the step of sending a continue message in the 
execution controller comprises the step of 
sending a continue message after a predeter- 
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mined time period in which no suspend execu- 
tion signal packets are received. 

7. The method of claim 4, characterized in that: 

5 

the suspend execution signal is represented by 
a suspend execution signal packet and the 
continue execution signal is represented by a 
continue execution signal packet; and 
the step of sending a suspend message in the 10 
execution controller comprises the step of 
sending the suspend message in response to a 
suspend execution signal packet; and 
the step of sending a continue message in the 
execution controller comprises the step of is 
sending a continue message in response to a 
continue execution signal packet. 
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